home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ Jun 89 / V0067-Re Object Pascal-Jun89 < prev    next >
Encoding:
Text File  |  1989-06-26  |  3.9 KB  |  87 lines  |  [TEXT/GEOL]
  1. Item    3347047                         21-June-89        19:23
  2.  
  3. From:   ROSENSTEIN1                     Rosenstein, Larry
  4.  
  5. To:     D2086                           Efficient Field Svc, C Faith, PRT
  6.  
  7. cc:     MACAPP.TECH$                    MACAPP Tech
  8.  
  9. Sub:    re Object Pascal
  10.  
  11. You want a way for TAbstract.Foo to tell whether the caller overrided Foo or
  12. not.  My idea was to move the functionality from TAbstract.Foo to
  13. TAbstract.Bar, and make TAbstract.Foo signal an error.
  14.  
  15. In the subclass TConcrete, TConcrete.Foo would call Bar to get the appropriate
  16. functionality.  This is not desirable alternative, but I don't know of any
  17. lanuguage that provides the capability you want.
  18.  
  19. It seems to me that if a method has code in it, then that code should perform
  20. some task.  It shouldn't perform half of a task and require someone to override
  21. the method to perform the other half.  I think you should decompose the thing
  22. you want to do into finer parts, and decide which can be implemented
  23. generically and which need to be implemented for a specific subclass (e.g. in a
  24. specific database).
  25.  
  26.  
  27. For example, it may make sense for TAbstract.Foo call another method, and make
  28. that method the one that signals an error if it is not overridden.  This sort
  29. of turns the problem around: instead of letting the subclass decide when to
  30. invoke the superclass' functionality, the superclass determines when to invoke
  31. the subclass'.
  32.  
  33. >I cannot have the method DoSomething do anything in TAbstract and still warn
  34. >that it should be overriden.  (Maybe this is not desirable?)
  35.  
  36. You can't do this without digging through the object code at runtime, and I
  37. think that is undesirable.
  38.  
  39. re: method dispatching
  40.  
  41. Whether or not a particular JSR uses A5-relative addressing (ie, requires a
  42. jump table entry) or PC-relative addressing (doesn't), does depend on whether
  43. the caller and the callee are in the same segment.  This decision is made by
  44. the linker, and takes into account segmentation changes you might do on the
  45. link command line.  (The jump table is involved in cross-segment references, to
  46. load the segment if necessary and because the target address can change if the
  47. segment moves around.)
  48.  
  49. A method call is totally different from a normal procedure call.  Conceptually,
  50. all method calls result in a table lookup to find the address of the piece of
  51. code.
  52.  
  53. If you were to dump the output of the Pascal compiler, you would find that a
  54. method call is simply a JSR to a routine associated with the method.  This
  55. routine contains a call to the method dispatcher followed by the table of
  56. implementations for that method.  The dispatcher finds the right method to call
  57. and jumps to it.
  58.  
  59. Normally the method tables are stored in a separate segment so that each method
  60. call requires a jump table for the cross-segment reference.  The jump to the
  61. actual code also goes through the jump table for a couple of reasons.  First,
  62. it means the method dispatcher doesn't have to load segments itself.  Second,
  63. the method tables are smaller because they only need to contain the offset into
  64. the jump table, rather than a segment number and offset into the segment.
  65.  
  66. When a method is optimized, calls are redirected to the actual method, rather
  67. than to the method table.  At this point, the situation is the same as that of
  68. a regular procedure, and the call with be PC-relative if the caller and callee
  69. end up in the same segment.
  70.  
  71. Remapping the method tables to eliminate the initial jump table entry would not
  72. provide a significant performance improvement.  The method tables are always
  73. loaded, so this simply involves an extra JMP instruction.  This is small
  74. compared to the time needed to look up the method and execute it.
  75.  
  76. My initial thought was that the runtime implementation depends on having the
  77. method tables in a different segment, but I can't remember exactly why so
  78. perhaps it can be done.  Unfortunately, I don't think there is an MPW tool that
  79. will remap the segment for an individual routine.
  80.  
  81. Larry
  82.  
  83.  
  84.  
  85.  
  86.  
  87.